dev.Dockerfile: allow forcing lnd/tapd/taprpc/loop repo - rebased #1119
Conversation
We can now use the LND_REPO, TAPROOT_ASSETS_REPO, TAPRPC_REPO, and LOOP_RPC build arguments to force a specific repo to be used so that commits referenced by LND_VERSION, TAPROOT_ASSETS_VERSION, TAPRPC_VERSION, and LOOP_VERSION don't have to exist in the default repository. If any of these build arguments are not defined, the build continues using the default repository for that module. NOTE: If these arguments ARE defined then the corresponding `_VERSION` argument MUST also be defined, otherwise the build continues using the default repository defined for that module.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @ZZiigguurraatt, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly enhances the dev.Dockerfile by providing greater flexibility in managing external Go module dependencies. It allows users to specify not just custom versions, but also custom Git repositories for core components like lnd, taproot-assets, taprpc, and loop, which is crucial for development and testing with specific forks or unmerged changes.
Highlights
- Enhanced Dependency Management: Introduced new build arguments (
LND_REPO,TAPROOT_ASSETS_REPO,TAPRPC_REPO,LOOP_REPO) indev.Dockerfileto allow specifying alternative Git repositories forlnd,taproot-assets,taprpc, andloopmodules. This enables building with specific commits or forks that might not exist in the default upstream repositories. - Conditional Module Replacement: The build process now conditionally uses
go mod edit -replacewhen a custom repository is provided via a_REPOargument, ensuring that the specified repository and version are used. If no custom repository is specified, it falls back togo get. - New
LOOP_VERSIONSupport: Added support for specifying a customLOOP_VERSIONand its correspondingLOOP_REPOfor theloopmodule, expanding the configurable dependencies. - Argument Dependency Clarification: Clarified in comments that if a
_REPOargument is defined, its corresponding_VERSIONargument must also be defined for the custom repository to be utilized during the build process.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature to the dev.Dockerfile, allowing developers to specify custom repositories for lnd, taproot-assets, taprpc, and loop. This greatly improves flexibility for testing against unmerged commits or forks. The implementation is functionally correct, but there's an opportunity to improve the efficiency and maintainability of the RUN command that handles these dependencies by reducing code duplication and avoiding redundant go mod tidy calls.
guggero
merged commit d51de24
into
lightninglabs:tapd-main-branch
3 participants
rebased version of #1118
We can now use the LND_REPO, TAPROOT_ASSETS_REPO, TAPRPC_REPO, and
LOOP_RPC build arguments to force a specific repo to be used so that
commits referenced by LND_VERSION, TAPROOT_ASSETS_VERSION,
TAPRPC_VERSION, and LOOP_VERSION don't have to exist in the default
repository. If any of these build arguments are not defined, the build
continues using the default repository for that module.
NOTE: If these arguments ARE defined then the corresponding
_VERSION argument MUST also be defined, otherwise the build continues
using the default repository defined for that module.